Ask a plant manager what a work order is and you’ll get a confident answer in about two seconds. Ask an MES implementation team the same question three months into a project and you’ll get a long pause, followed by a much longer meeting. That gap is where most first-year MES pain lives.
The root cause is almost always the same: someone took the work order structure that already existed in the ERP system and used it as the blueprint for the MES. It compiles. It demos fine. And then somewhere around the first engineering change order, or the first time a batch needs to split across two lines, the model buckles.
An ERP work order and an MES work order are not the same object
An ERP work order — whether it comes out of SAP, Oracle, or a mid-market planning system — is fundamentally a planning artifact. It answers questions like: what needs to be made, how much, by when, against which cost center or sales order, and what’s the standard cost roll-up. It exists in a world of weeks and shifts, not seconds and states. It’s built for material requirements planning and financial visibility, and it’s very good at that job.
An MES work order — or, more precisely, a dispatch or execution order — has to answer a completely different set of questions. Which specific routing steps apply to this unit of production right now? What resource (line, cell, operator, tool, fixture) is it assigned to? What is its current state, and what states can it legally move to next? What genealogy does it need to carry forward — lot, serial, parent-child component consumption? What in-process quality holds apply to it?
This is the distinction ISA-95 is actually trying to draw when it separates the business planning and logistics layer (Level 4) from the manufacturing operations management layer (Level 3). The standard doesn’t use the phrase “work order” uniformly across vendors, but its concept of a production schedule feeding a production performance record, mediated by an operations definition, is exactly the ERP-to-MES translation most teams skip. ISA-95 treats the Level 4 schedule as an input, not as the thing you execute against directly. Somewhere in between, that planning artifact has to be decomposed into something with routing logic, resource constraints, and state transitions. That decomposition step is the actual scoping work, and it’s the part teams routinely skip because the vendor demo made it look like a mapping exercise instead of a design exercise.
Start with splits and merges, not with screens
Before you look at a single MES screen, work through how production quantity actually moves through your plant, because this is where rigid models fail first.
Ask: does one ERP work order ever need to become multiple MES dispatch records? It almost always does. A work order for a thousand units might run across two parallel lines, or get split because a tool goes down mid-run, or get partially released to work off existing WIP while the rest waits on a component. If your MES model assumes a strict one-to-one relationship between the ERP work order and the execution record, the first split forces someone to fake it — closing out partial quantities against a phantom order, or manually re-keying a new work order in the ERP just to give the MES something clean to attach to. That workaround becomes permanent within a quarter, and now your genealogy and your cost reporting are built on a fiction.
Merges are the mirror problem. Kitting operations, batch blending, and sub-assembly consumption routinely need to combine output from multiple upstream orders into a single downstream execution record. If the model can’t represent “this dispatch consumed material from three parent lots,” you lose traceability at exactly the point regulators or customers are most likely to ask for it.
The scoping exercise here is concrete: walk your actual routings, floor by floor, and write down every real instance in the last year or two where a single planned quantity had to be split, combined, reworked, or rerouted outside the “happy path.” That list is your split/merge rulebook. It’s tedious. It’s also the single highest-leverage thing you can do before configuration starts, because retrofitting split/merge logic into a live MES is a rebuild, not a patch.
How many states do you actually need?
Vendor demos love state diagrams. You’ll see Created, Released, Dispatched, In Process, Paused, Completed, Closed — sometimes a dozen or more, each with its own icon and color. It looks thorough. It is also frequently more granularity than your operation needs, and unnecessary states are not free — each one is a decision point an operator has to make correctly, a transition your integration layer has to handle, and a report column someone has to explain to an auditor.
The right number of states is the smallest set that maps to a real operational decision or a real data capture requirement. If your process never meaningfully distinguishes between “released to the floor” and “material staged,” don’t model them separately just because the software supports it. Conversely, if rework is common in your environment, you likely need an explicit state for it rather than letting reworked units silently re-enter the main flow, because that’s exactly where genealogy and yield reporting quietly break.
A practical test: for every proposed state, ask who changes it, what triggers the change, and what decision or record depends on knowing the system is in that state. If you can’t answer all three, you probably don’t need the state — you need a status flag or a timestamp instead.
Build in the exceptions, not just the happy path
The failure mode to design against explicitly is over-rigidity: a model so tightly bound to the standard routing that engineering changes, rework loops, and off-spec deviations have nowhere to go. This shows up constantly with engineering change orders that need to apply mid-run — some units on the floor should finish under the old routing, units not yet started should pick up the new one, and the system needs to know which is which without an operator guessing. It shows up with rework, where a unit needs to re-enter a prior operation without being treated as a brand-new work order that breaks its genealogy trail. And it shows up with partial completions, where a work order needs to close with a quantity variance that’s normal for your process, not an error state that blocks month-end.
None of these are edge cases in any real plant. They’re a normal part of production, and if your work order model can’t absorb them without a workaround, you haven’t actually scoped an execution model — you’ve just relabeled the ERP’s planning structure and called it MES.
Why this matters for the current wave of MES decisions
A meaningful number of plants are heading into renewal or replacement decisions this budget cycle, evaluating platforms like Opcenter, Proficy, Critical Manufacturing, and Plex, among others. It’s tempting to treat the work order model as a configuration detail you’ll sort out during implementation, something the systems integrator handles once the contract is signed. That’s backwards. The work order and dispatch model is closer to a data architecture decision than a configuration setting — it determines what your traceability actually looks like, what your operators are asked to decide in real time, and how much manual workaround accumulates in year one. Get it wrong and you’re not just filing change requests; you’re fighting the shape of the system for the life of the contract. Scope it before you buy, not after.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
